Computer management of many business functions has grown exponentially in the last two decades. Originally, computers operated as efficient record keepers and large databases were stored and accessed as needed. More powerful programs were developed, and product and account management functions were automated. Exemplary systems include an asset management system disclosed in U.S. Pat. No. 4,346,442 to Musmanno, and automated trading system of U.S. Pat. No. 4,674,044 to Kalmus, et al.--the contents of both patents are incorporated by reference as if restated in full. These systems include programmed decision-making on an account or product basis and substantially enhance performance and efficiency of the system proprietor.
However, the growth of individual products and the associated software in product management has created a second tier of system management issues. In financial services, a provider may offer several dozen different products or accounts, each having a collection of individual processing characteristics specific to that type of product or account. Indeed, as is conventional in this industry, accounts and products are added to the servicer's portfolio of offerings in an incremental fashion. The developers of the software that support the products and account innovations work incrementally and largely independently. Accordingly, these developers--consistent with their diverse backgrounds and objectives--create products and services that lack any integration therebetween or, for that matter, uniformity in design approach.
In particular regard to processing financial and brokered transactions for large clients, such as major corporations and institutional investors, the utilization of product-specific or account-type specific systems, as is typically implemented, creates various problems. One resultant problem is the duplication of data, function, and personnel for similarly-structured products administered on different systems; the evolution of these systems is not as dependent upon differing needs compared with related systems but of poor integration of similarly functions and data handled differently among the systems. Another problem is unmanageable maintenance of these types of systems; the functions performed by these systems, and the code needed to implement such functions, have grown to a size and convoluted complexity where systems integration and testing is virtually impossible and development results in the interruption of business activities. Yet another problem is the sheer complexity of the code, which is so convoluted and particular that structural and efficiency changes are difficult if not impossible to implement.
Still other shortcomings exist in present systems. Given the present global market, in which trading can be performed continuously, processing in "batch" mode is an unacceptable practice. Financial transactions can be initiated across a broad range of hardware and/or software platforms, among distributed locations, making integration and continuous processing difficult to achieve. Virtually inherent in such varied platforms are conflicting problems, the redundant generation of the same data, and the lack of coherent standards and controls for achieving systems integration.
The legacy of the above environment is a group of powerful software applications operating and accessible only independently of each other. These applications are supported and updated inconsistently across the enterprise, by different groups of engineers, with differing objectives and time frames. The end result is multiple standards, redundant files, and often data errors and failed system cross-processing. In addition, the disparate applications can create a maintenance nightmare due to the complexity and lack of common architecture.
It was with this recognition of such problems with past systems that formed the impetus and starting point for the present invention.